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Sir: 
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II. RELATED APPEALS AND INTERFERENCES 

Appellant knows of no other appeals or interference proceedings related to the present 

appeal. 

III. STATUS OF CLAIMS 

Pending claims 1-17 stand rejected. No claims are allowed or objected to. The claims on 
appeal are claims 1-17. 

IV. STATUS OF AMENDMENTS 

A preliminary Amendment was filed on July 27, 2001. In the preliminary Amendment, 
claims 1, 6, 7, 9, 10 and 15 were amended. An Amendment was filed under 37 CFR 1.111 on 
November 12, 2004 in which claims 1, 7, 9, 10 and 15 were amended. Each of these 
Amendments has been entered. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

The present invention is directed to a data transmission method. 

With respect to claim 1, a data transmission method (see e.g., the flowcharts of Figs. 5 
and 6) between a server (see e.g., server 3 in Fig. 1) incorporating a database (see e.g., database 2 
in Fig. 1) therein and a client machine (see e.g., client machine 4 in Fig. 1) interlinked via a 
network (see e.g., network 5 in Fig. 1), data as in a table format retrieved from the database 
based on a retrieval command (see e.g., step S101 in Fig. 5) from the client machine being 
transmitted from the database server to the client machine, the method comprising: 
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a data table generating step (see e.g., steps S101 and SI 02 in Fig. 5; and page 21, line 25 
- page 22, line 17) generating a retrieval data table (see e.g., retrieval data table 37 in Fig. 8) 
containing the retrieved data and a data attribute table (see e.g., a data attribute table 36 in Fig. 7) 
containing attribute information of the retrieved data, in a memory area on a server side; 

a transmission data generating step (see e.g., step S104 in Fig. 5; and page 22, line 18 - 
page 23, line 7) of serializing all items contained in the data attribute table and retrieval data 
table into a single string without adding additional information between the items (see e.g., 
transmission data 38 in Fig. 9; and page 24, lines 1-8); 

a control information adding step (see e.g., step SI 08 in Fig. 5; and page 23, lines 17 - 
23) of adding control information (see e.g., control information 39 in Fig. 10) corresponding to 
the transmission data, to a head of the transmission data; 

a data transmitting step (see e.g., step SI 10 in Fig. 5; and page 23, lines 24-28) of 
transmitting the transmission data generated in the transmission data generating step, to the client 
machine; 

a data table regenerating step (see e.g., step S204 in Fig. 6; and page 24, lines 17-22) of 
regenerating the data attribute table and the retrieval data table in a memory area on the client 
side, from the transmission data transmitted; and 

a data reading step (see e.g., step S205 in Fig. 6; and page 24, lines 23-27) of reading 
required data from the regenerated data attribute table and retrieval data table. 

With regard to claim 7, a database retrieval method (see e.g., Figs. 12 and 13; and page 
26, line 1 1 - page 27, lines 12), between a micro server (see e.g., micro server 45, 46 in Figs. 12 
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and 13) and a main server (see e.g., database server 3 in Fig. 12) interconnected via a 
communication link (see e.g., digital link 10 and network 5 in Fig. 12), the micro server 
receiving a retrieval command from a plurality of client machines (see e.g., client machines 4 in 
Fig. 12), the main server incorporating a database (see e.g., database 2 in Fig. 12), the retrieval 
command (see e.g., step SI 01 in Fig. 5) being forwarded via the micro server, data as in a table 
format retrieved from the database being forwarded to the client machine via the micro server, 
the method comprising: 

steps performed on the main server side, of generating (see e.g., steps SI 01 and S102 in 
Fig. 5; and page 21, line 25 - page 22, line 17) and storing in a memory area an extracted 
retrieval data table (see e.g., retrieval data table 37 in Fig. 8) and a data attribute table (see e.g., a 
data attribute table 36 in Fig. 7) containing description on data attribute of the retrieval data table, 
of serializing all items in the retrieval data table and data attribute table into a single string of 
transmission data without adding additional information between the items (see e.g., step SI 04 in 
Fig. 5; page 22, line 18 - page 23, line 7; transmission data 38 in Fig. 9; and page 24, lines 1-8), 
of adding control information (see e.g., step S108 in Fig. 5; page 23, lines 17 - 23; and control 
information 39 in Fig. 10) corresponding to the transmission data, to a head of the transmission 
data, and forwarding to the micro server; and 

steps performed on the client side, of regenerating (see e.g., step S204 in Fig. 6; and page 
24, lines 17-22) from the transmission data and storing in a memory area the data attribute table 
and the retrieval data table, of reading (see e.g., step S205 in Fig. 6; and page 24, lines 23-27) 
required data from the data attribute table and the retrieval data table, and of forwarding the read 
data to the client machine that issued the retrieval command. 

4 



09/889,559 

With regard to claim 9, a data transmission method (see e.g., Fig. 1 1; and page 25, line 28 
- page 26, line 10) in a database system where a plurality of servers (see e.g., servers 3a to 3d in 
Fig. 11) each incorporating a database (see e.g., databases 2a to 2d in Fig. 1 1) are interconnected 
via a communication link (see e.g., digital link 10 and network 5 in Fig. 1 1), data as in a table 
format being transmitted between the servers, the method comprising: 

steps performed in one of the servers; of generating (see e.g., steps S101 and S102 in Fig. 
5; and page 21, line 25 - page 22, line 17) and storing in a memory area an extracted retrieval 
data table (see e.g., retrieval data table 37 in Fig. 8) and a data attribute table (see e.g., a data 
attribute table 36 in Fig. 7) containing description on data attribute of the retrieval data table; of 
serializing the retrieval data table and the data attribute table into a single string of transmission 
data without adding additional information between the items (see e.g., step S104 in Fig. 5; page 
22, line 18 - page 23, line 7; transmission data 38 in Fig. 9; and page 24, lines 1-8); of adding 
control information (see e.g., step S108 in Fig. 5; page 23, lines 17-23; and control information 
39 in Fig. 10) corresponding to the transmission data, to a head of the transmission data; and of 
forwarding to another of the servers; and 

steps performed in said another server: of regenerating (see e.g., step S204 in Fig. 6; and 
page 24, lines 17-22) from the transmission data and storing in a memory area the data attribute 
table and the retrieval data table; of reading (see e.g., step S205 in Fig. 6; and page 24, lines 23- 
27) required data from the data attribute table and the retrieval data table and performing 
required processing to the read data. 
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With regard to claim 10, a computer-readable recording medium (see e.g., page 14, lines 
3 - 21) for application to a server (see e.g., server 3 in Fig. 1) incorporating a database (see e.g., 
database 2 in Fig. 1) therein and a client machine (see e.g., client machine 4 in Fig. 1) 
interconnected via a communication link (see e.g., digital link 10 and network 5 in Fig. 3), the 
medium storing a program (see e.g., page 29, lines 13-20) for transmitting data as in a table 
format that is retrieved from the database at a command (see e.g., step SI 01 in Fig. 5) from the 
client machine, to the client machine, characterized in that the program includes: 

retrieval data table generating means (see e.g., retrieval data table generating means 16 in 
Fig. 3) of generating a retrieval data table extracted by the retrieval, in a memory area; 

data attribute table generating means (see e.g., data attribute table generating means 17 in 
Fig. 3) of generating a data attribute table containing description on data attribute of the retrieval 
data table, in a memory area; 

transmission data generating means (see e.g., transmission data generating means 18 in 
Fig. 3) of serializing items in the data attribute table and retrieval data table into a single string 
without adding additional information between the items; 

data analyzing means (see e.g., data analyzing means 19 in Fig. 3) of determining 
application or non-application of a compressing means depending on data attribute of the 
transmission data. 

With regard to claim 15, a data transmission apparatus (see e.g., Fig. 14; and page 27, 
line 13 - page 28, line 18) comprising a database-side micro server (see e.g., micro server 45 in 
Fig. 14) connected with a database server (see e.g., database server 3 in Fig. 14) incorporating a 
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database (see e.g., database 2 in Fig. 14) therein and a client-side micro server (see e.g., micro 
server 47 in Fig. 14) connected with a client machine (see e.g., client machines 4 in Fig. 14), for 
exchange of data as in a table format, between the database server and the client machine via a 
network (see e.g., network 5 in Fig. 14) and the micro servers, wherein 
database-side micro server includes: 

a computing device, a storing device, and a data input-output device capable of inputting 
and outputting data to and from the database server and the network (see e.g., page 26, lines 17- 
21); a retrieval command generating program of converting a retrieval command data (see e.g., 
step SI 01 in Fig. 5) inputted from the client-side micro server into a retrieval command for 
execution of the database retrieval; 

a data table generating program (see e.g., steps S 101 and S 102 in Fig. 5; and page 21, line 
25 - page 22, line 17) of generating a retrieval data table (see e.g., retrieval data table 37 in Fig. 
8) obtained by the database retrieval, in the storing device; 

a data attribute table generating program (see e.g., steps SI 01 and SI 02 in Fig. 5; and 
page 21, line 25 - page 22, lines 17) of generating a data attribute table (see e.g., a data attribute 
table 36 in Fig. 7) containing description of data attribute of the retrieval data table, in the storing 
device; 

a transmission data generating program (see e.g., step S104 in Fig. 5; and page 22, line 18 
- page 23, line 7) of serializing all items in the retrieval data table and data attribute table into a 
single string without adding additional information between the items, thereby generating a 
transmission data (see e.g., transmission data 38 in Fig. 9; and page 24, lines 1-8); 
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a control information adding program (see e.g., step SI 08 in Fig. 5; and page 23, lines 17 
- 23) of adding control information (see e.g., control information 39 in Fig. 10) corresponding to 
the transmission data, to a head of the transmission data; 

a data exchange program of exchanging data with the database server; and 

a data transmission-reception (see e.g., data reception-transmission processing means 8 in 
Fig. 2; and page 19 5 lines 12-18) program for information exchange with the client-side micro 
server via the network; whereas 

the client-side micro server includes: 

a computing device, a storing device, and a data input-output device (see e.g., page 26, 
lines 17-21) capable of inputting and outputting data to and from the database server and the 
network; 

a retrieval (see e.g., retrieval data processing means 15 in Fig. 2; and page 19, lines 19- 
28) serializing the command data generating retrieval command data program given by the client 
machine into the retrieval command data; 

a data table regenerating program (see e.g., step S204 in Fig. 6; and page 24, lines 17-22) 
of regenerating, in the storing device, the retrieval data table and the data attribute table from the 
transmission data and the control information received from the server-side micro server; and 

a retrieved data reading program (see e.g., step S205 in Fig. 6; and page 24, lines 23-27) 
of reading the retrieved data from the regenerated retrieval data table and the data attribute table. 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 



Appellant appeals the following rejections: 

A. The rejection of claims 1-17 under 35 USC 1 12, first paragraph, as failing to comply with 
the enablement requirement. 

B. The rejection of claims 1, 6 - 9 and 15 under 35 U.S.C. §102 over Heilsberg et al. 
(USP 6,151,602); 

C. The rejection of claims 4 and 5 were rejected under 35 U.S.C. §103 over Heilsberg ; and 

D. The rejection of claims 2, 3, 10, 1 1, 12, 14 and 16 were rejected under 35 U.S.C. §103 
over Heilsberg, in view of Coganetal . (USP 5,406,380). 



VII. ARGUMENTS 
A. Rejection of claims 1-17 under 35 USC 112, first paragraph, as failing to comply 
with the enablement requirement. 

Claims 1-17 

The Examiner takes the following position in the final rejection: 

In referring to claim 1, the "step of regenerating the data attribute table and the retrieval 
data table" when there is no information between serialized data items. . . . 
The specification of the instant application gives an example of serialized data (Fig. 9, 
element 38) that is to be regenerated as a table. This is to be done with the control data 
with consists of "data size 41, method of compression 42, size of the compressed data 43 
and return code 44" (page 23, lines 21-22). It is unclear as to how the serialized data 
string would be regenerated, as each data item is (or could be) a different size. If the 
control data contains the size of each of the individual data items then the control data 
would contain the same number of elements as the returned string. This disclosure would 
not enable any person skilled in the art to make and use the subject matter defined by 
each of the rejected claims without undue experimentation. 
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However, it is respectfully submitted that the Examiner is clearly mis-characterizing the 
features of the present claimed invention. 



More specifically, claim 1 was amended in the amendment dated November 12, 2004 to 
recite a transmission data generating step of serializing all items contained in the data attribute 
table and retrieval data table into a single string without adding additional information between 
the items . 

As the Examiner noted, Fig. 9 of the present application shows an example of the 
transmission data 38 generated from the data tables shown in Fig. 7 and Fig. 8, which 
information contained in each item of each row of the data attribute table 36 and the retrieval 
data table 37 is simply connected into a single string of a text data without any information 
between added between the items. That is, the transmission data generating step converts a 
number of data included in the tables into a single string of data. 

Then, as shown in Fig. 10 of the present application, the control information adding means 
20 adds the control information 39 to the head of a compressed transmission data 40 (SI 08) and 
not between the items in the single string. 

That is, since size, items and so on of the retrieval data table are different every time the 
retrieval is made, information on these characteristics must be sent to the client machine in order 
to regenerate the tables from the transmission data which is sent in the form of the single string. 
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For this reason, the control information in accordance with the characteristic of the transmission 
data is added to the head of the transmission data. Adding these pieces of control information 
enables the receiving side to quickly reserve a necessary size of memory area for example, 
facilitating smooth transmission of the data. 

Claim 1 also recites the data table regenerating step of regenerating the data attribute 
table and the retrieval data table in a memory area on the client side, from the transmission data 
transmitted. 

For example, Fig. 6 shows a processing procedure of received data on the client side. The 
data sent from the server 3 is received by the data reception-transmission processing means 12 of 
the client machine 4 (S201). The control information of the received data is read to determine if 
there is need for decompression (S202). If the data is compressed, the data decompressing 
means 34 restores the string data 38 shown in Fig. 9 (S203). 

Next, the data attribute table 36 and the retrieval data table 37 shown in Fig. 7 and Fig. 8 
are separated from the data string 38 and stored in a memory area of the client machine by the 
data table regenerating means 33 (S204). With the above procedure, the same data as retrieved 
in the server is formed in the client machine. 

In addition, the Examiner considers "It is unclear as to how the serialized data string would 
be regenerated, as each data item is a different size." 
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In a relational database, data takes a form of table. A table is made up of a number of rows 
having the same structure. Each of the rows contains items. The size of data is decided with the 
number of rows, and the size of each item of the same column being fixed. Since the character 
strings of each attribute data is limited by SQL, attribute data (table) is regenerated easily from the 
serialized data string without adding additional information between the items. Therefore, a retrieval 
data table is regenerated if the attribute of each item is known. 

In view of the above, it is respectfully submitted that one of ordinary skill would be able 
to make and/or use the subject matter of present claimed invention as described in the present 
specification as originally filed. Accordingly, withdrawal of this rejection is respectfully 
requested. 

Moreover, it is respectfully submitted that the Examiner has failed to provide any type of 
indication in the Advisory Action dated December 6, 2005 as to whether this rejection has been 
withdrawn or the rejection still stands in view of the arguments presented in the After Final 
Response dated October 28, 2005. As such, in order to provide clarification regarding for this 
issue, a telephone conference was conducted with the Examiner on December 19, 2005 during 
which the Examiner indicated that the rejection of claims 1-17 under 35 USC 1 12, first 
paragraph, has been overcome in view the arguments presented in the After Final Response 
dated October 28, 2005. 
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B. Rejection of claims 1,6-9 and 15 under 35 U.S.C. §102 over Heilsberg et al . 
(USP 6,151,602). 

Claims 1,6-9 and 15 

Independent claim 1 recites, inter alia, "a transmission data generating step of serializing 
all items contained in the data attribute table and retrieval data table into a single string without 
adding additional information between the items ." Independent claims 7, 9 and 15 include 
similar features. 

For example, as shown in Fig. 9 and as discussed on pages 6 and 7 of the present 
specification, the serialization of the data performed in the transmission data generating step is 
achieved by converting all of the items included in each of the data attribute tale and the retrieval 
data table into a single, continuous string of data. That is, there is no specific need at all for 
insertion of any identification information between the serialized data string made from the data 
attribute table and the serialized data string made from the retrieval data table. With the above 
arrangement, as compared with the conventional method in which identification information is 
inserted before or after each item, it has become possible to dramatically reduce the amount of 
transmission data. In other words, because there is no identification codes and so on inserted 
between the items, the amount of data is remarkably smaller than in the conventional 
transmission method. That is, the present invention relates to the data formatting in the 
application level, and does not relate to packet data. 
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Heilsberg teaches no more than the conventional method mentioned in the present 
specification. In particular, Heilsberg discloses the use of identification information before each 
row. As described at columns 13 and 14 of Heilsberg , the row data for a data packet includes a 
row status field (iRowCount) in the header, as well as a null indicator bit array (InullBits). Such 
additional descriptor information is inserted before each row or "item." 

Moreover, it is clear that Fig. 4 of Heilsberg shows a packet format. And the HEADER 
(410) in Fig. 4 is a PACKET HEADER (Col. 1 1 lines 60 to 66). Namely each packet data has 
column descriptor, and the amount of data of one packet is restricted by the communications 
system. For this reason, in order to arrange column descriptors to identify the next raw data, a 
special communication program like Heilsberg 's is required (Col. 1 1 lines 16 to 59 and table 5). 
That is, a standard communication system for adding a packet header cannot be used as it is. 

On the other hand, the data format of the present invention (fig. 10) is not a packet format. 
That is, there is no mention of a generation method of packet data in the present specification. 
However, it is technical common sense that many packets are generated by dividing a long 
sequence data and these packets are transmitted one by one with TCP/IP. More specifically, as 
discussed in lines 24-29 in page 23 of the present specification, after the control information 39 
is added to the compressed transmission data 40 (Fig. 10), the data is forwarded to the data 
reception-transmission processing means 8 (step SI 09), and then is transmitted to the client 
machine 4 in accordance with the TCP/IP protocol, as a single string of data (SI 10). 
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Therefore, as already explained, in the present invention, attribute data and retrieval data 
are unified into a single string of data in the application level. And the single string of data is 
divided into packets by the operation system (TCP/IP), so the attribute data (column descriptor) 
is not attached to each packet. In other words, the step of dividing the single string of data into 
packets by the operation system (TCP/IP) corresponds to the data transmitting step, and not the 
transmission data generating step, of claim 1. 

In the case of Hejlsberg, items data are treated in a packet level as it is. For this reason, it 
is necessary to generate each packet data in the good portion of the pause corresponding to the 
column descriptors. For this reason, the filling rate of data to one packet becomes small, and the 
number of packets increases. 

In the present invention, the single string data is divided in every portion (all data string 
shown in Fig. 10), and packet data can be generated without being dependent on each items data 
characteristic. Therefore, it can become possible to stuff data into one packet with all its might, 
and the number of packets can be decreased. 

In the advisory Action dated December 6, 2005, the Examiner explicitly relies on the 
disclosure in col. 2, lines 64 - col. 3, line 4; col. 8, lines 36-48; and col. 20, lines 64 - col. 21, 
line 7, and based on such disclosure concludes that "Hejlsberg teaches processing actual data 
sequentially and after all the fields of all records have been processed adding an indicator at the 
end of the stream (not between records or fields)." 
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However, it is respectfully submitted that in col. 2, lines 64 - col. 3, line 4 Heilsberg 
explicitly teaches that data is returned to the client by means of a "data packet," which as already 
noted-above fails to constitute a transmission data generating step of serializing all items 
contained in the data attribute table and retrieval data table into a single string without addim 
additional information between the items , as called for in claim 1 . 

Further, with regard to the disclosure in col. 8, lines 36-48 of Heilsberg , the examiner is 
arguing about Null Data. That is, the Examiner considers "By eliminating non information and 
given the streaming format, the system can transmit data in compact format one which it is 
optimized for transmission across a communication network." However, there are very few 
items without data. Therefore, it cannot be said that the data can be optimized. 

Finally, with regard to the disclosure in col. 20, lines 64 - col. 21, line 7 of He jlsberg , it 
is respectfully submitted that at step 505 (Figure 5), the system loops through all data records of 
the result set and writes out the corresponding field values into a stream including descriptors. 
Indeed, Heilsberg relies on the existence of the intervening descriptors in the data stream 
(including the inserted row data header information mentioned above) in order to achieve a 
correct interpretation of the stream data (see e.g. column 21, lines 1 - 4). Such teachings in the 
primary reference to Heilsberg are directly contrary to the present invention that avoids inserting 
such additional information between each item. Indeed, the primary reference to Heilsberg is 
contrary to the present claimed "serializing all items contained in the data attribute table and 
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retrieval data table into a single string without adding additional information between the 
items." 

It is well settled that: 

"A claim is anticipated only if each and every element as set forth in the claim is 
found, either expressly or inherently described, in a single prior art reference." 
Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1567, 7 USPQ2d 1057 
(Fed. Cir. 1988)." 

As such, it is respectfully submitted that Heilsberg fails to anticipate the features of claim 
1, since Heilsberg fails to disclose or fairly suggest the features of claim 1 concerning a 
transmission data generating step of serializing all items contained in the data attribute table 
and retrieval data table into a single string without adding additional information between the 
items. It is further submitted that Heilsberg fails to anticipate claims 7, 9 and 15 for the same 
reasons as discussed above with regard to claim 1 . 

Further still, it is respectfully submitted that in the present invention, two tables, a 
retrieval data table and a data attribute table, are generated in the server on the transmission side, 
and required data is read from these two tables with a SQL command, whereas in contrast 
Heilsberg fails to indicate that two tables are generated. Therefore, even if, Heilsberg can 
recognize transmission data, there is no teaching in Heilsberg regarding the ability to extract the 
retrieval and data attribute tables from the transmitted data. 
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As such, it is respectfully submitted that Heilsberg fails to anticipate the features of claim 
1, since Heilsberg also fails to disclose or fairly suggest the features of claim 1 concerning a data 
table generating step of generating a retrieval data table containing the retrieved data and a 
data attribute table containing attribute information of the retrieved data, in a memory area on a 
server side ... a data table regenerating step of regenerating the data attribute table and the 
retrieval data table in a memory area on the client side, from the transmission data transmitted; 
and a data reading step of reading required data from the regenerated data attribute table and 
retrieval data table. It is further submitted that Heilsberg fails to anticipate claims 7, 9 and 15 
for the same reasons as discussed above with regard to claim 1 . 

C. Rejection of claims 4 and 5 were rejected under 35 U.S.C. §103 over Heilsberg . 

Claims 4 and 5 

It is respectfully submitted that dependent claims 4 and 5 are allowable over Heilsberg 
for at least the reasons set forth above with regard to independent claim 1 . 

D. Rejection of claims 2, 3, 10, 11, 12, 14 and 16 were rejected under 35 U.S.C. §103 
over Heilsberg, in view of Cogan et al . (USP 5,406,380). 

Claims 2,3, 10, IK 12, 14 and 16 

Independent claim 10 recites, inter alia, retrieval data table generating means of 
generating a retrieval data table extracted by the retrieval in a memory area; data attribute 
table generating means of generating a data attribute table containing description on data 
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attribute of the retrieval data table, in a memory area; transmission data generating means of 
serializing items in the data attribute table and retrieval data table into a single string without 
adding additional information between the items. As discussed above, Heilsberg fails to disclose 
or fairly suggest such claimed features. 

In addition, Section 2143 of the MPEP has specifically stated that: 

"To establish a prima facie case of obviousness, three basic criteria must be met. 
First, there must be some suggestion or motivation, either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the 
art, to modify the reference or to combine reference teachings. Second, there 
must be a reasonable expectation of success. Finally, the prior art reference must 
teach or suggest all the claimed limitations. The teaching or suggestion to make 
the claimed combination and the reasonable expectation of success must both be 
found in the prior art, and not based on applicant's disclosure. In re Vaeck, 947 
F.2d 466, 20 USPQ2d 1438 (Fed. Cir. 1991)." 

It is respectfully submitted that the applied reference of Cogan et al fails to disclose or 
fairly suggest the above-noted drawbacks and deficiencies of Heilsberg concerning retrieval data 
table generating means of generating a retrieval data table extracted by the retrieval, in a 
memory area; data attribute table generating means of generating a data attribute table 
containing description on data attribute of the retrieval data table, in a memory area; 
transmission data generating means of serializing items in the data attribute table and retrieval 
data table into a single string without adding additional information between the items. 

As such, it is respectfully submitted that the Examiner has failed to establish a prima 
facie case of obviousness, since Cogan et al and Heilsberg , singly or in combination, fail to 
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disclose or fairly suggest the features of claim 10 concerning retrieval data table generating 
means of generating a retrieval data table extracted by the retrieval in a memory area; data 
attribute table generating means of generating a data attribute table containing description on 
data attribute of the retrieval data table, in a memory area; transmission data generating means 



For the above reasons, Appellant requests that the Board of Patent Appeals and 
Interferences reverse the Examiner's rejections of claims 1-17 

In the event this paper is not timely filed, appellant hereby petitions for an appropriate 
extension of time. The fee for any such extension may be charged to our Deposit Account No. 
50-2866, along with any other additional fees which may be required with respect to this paper. 



of serializing items in the data attribute table and retrieval data table into a single string without 



adding additional information between the items. 



VIII. CONCLUSION 



Respectfully submitted, 



WESTERMAN, R 
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Thomas ETBrown 
Attorney for Appellant 
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CLAIMS APPENDIX 

Claim 1 : A data transmission method between a server incorporating a database therein 
and a client machine interlinked via a network, data as in a table format retrieved from the 
database based on a retrieval command from the client machine being transmitted from the 
database server to the client machine, the method comprising: 

a data table generating step of generating a retrieval data table containing the retrieved 
data and a data attribute table containing attribute information of the retrieved data, in a memory 
area on a server side; 

a transmission data generating step of serializing all items contained in the data attribute 
table and retrieval data table into a single string without adding additional information between 
the items; 

a control information adding step of adding control information corresponding to the 
transmission data, to a head of the transmission data; 

a data transmitting step of transmitting the transmission data generated in the 
transmission data generating step, to the client machine; 

a data table regenerating step of regenerating the data attribute table and the retrieval data 
table in a memory area on the client side, from the transmission data transmitted; and 

a data reading step of reading required data from the regenerated data attribute table and 
retrieval data table. 
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Claim 2: The data transmission method according to claim 1, further comprising: a data 
compressing step on the server side, of compressing the serialized transmission data and 
including information on a method of the compression in the control information; and 

a data decompressing step on the client side, of decompressing the received data for 
generation of the transmission data. 

Claim 3: The data transmission method according to claim 1, further comprising: a 
compression determining step of determining whether or not the transmission data is to be 
compressed, in accordance with the data characteristic of the transmission data; and 

a data compression step of compressing the transmission data and including information 
on a method of the compression in the control information, if the compression determining step 
determines for the compression. 

Claim 4: The data transmission method according to claim 1, wherein all of the items 
contained in the data table extracted from the database and all of the items contained in the data 
attribute table are provided by text data. 

Claim 5: The data transmission method according to claim 1, wherein an item in the 
retrieval data table extracted from the database contains data other than text data. 

Claim 6: The data transmission method according to Claim 1, further comprising: 
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a retrieval command generating step performed on the client machine, of generating a 
serialized retrieval command; and 

a retrieval command data transmitting step of transmitting the retrieval command data to 

the server; and 

a retrieval command regenerating step performed on the server side, of converting the 
retrieval command data into a retrieval command that performs the database retrieval. 

Claim 7: A database retrieval method, between a micro server and a main server 
interconnected via a communication link, the micro server receiving a retrieval command from a 
plurality of client machines, the main server incorporating a database, the retrieval command 
being forwarded via the micro server, data as in a table format retrieved from the database being 
forwarded to the client machine via the micro server, the method comprising: 

steps performed on the main server side, of generating and storing in a memory area an 
extracted retrieval data table and a data attribute table containing description on data attribute of 
the retrieval data table, of serializing all items in the retrieval data table and data attribute table 
into a single string of transmission data without adding additional information between the items, 
of adding control information corresponding to the transmission data, to a head of the 
transmission data, and forwarding to the micro server; and 

steps performed on the client side, of regenerating from the transmission data and storing 
in a memory area the data attribute table and the retrieval data table, of reading required data 
from the data attribute table and the retrieval data table, and of forwarding the read data to the 
client machine that issued the retrieval command. 
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Claim 8: The database retrieval method according to Claim 7, 

wherein the micro server generates and forwards a serialized retrieval command data 
made from the retrieval command sent by the client machine, and the main server converts the 
forwarded retrieval command data into a retrieval command thereby executing the database 
retrieval. 

Claim 9: A data transmission method in a database system where a plurality of servers 
each incorporating a database are interconnected via a communication link, data as in a table 
format being transmitted between the servers, the method comprising: 

steps performed in one of the servers; of generating and storing in a memory area an 
extracted retrieval data table and a data attribute table containing description on data attribute of 
the retrieval data table; of serializing the retrieval data table and the data attribute table into a 
single string of transmission data without adding additional information between the items; of 
adding control information corresponding to the transmission data, to a head of the transmission 
data; and of forwarding to another of the servers; and 

steps performed in said another server: of regenerating from the transmission data and 
storing in a memory area the data attribute table and the retrieval data table; of reading required 
data from the data attribute table and the retrieval data table and performing required processing 
to the read data. 
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Claim 10: A computer-readable recording medium for application to a server 
incorporating a database therein and a client machine interconnected via a communication link, 
the medium storing a program for transmitting data as in a table format that is retrieved from the 
database at a command from the client machine, to the client machine, characterized in that the 
program includes: 

retrieval data table generating means of generating a retrieval data table extracted by the 
retrieval, in a memory area; 

data attribute table generating means of generating a data attribute table containing 
description on data attribute of the retrieval data table, in a memory area; 

transmission data generating means of serializing items in the data attribute table and 
retrieval data table into a single string without adding additional information between the items; 

data analyzing means of determining application or non-application of a compressing 
means depending on data attribute of the transmission data. 

Claim 11: The computer-readable recording medium according to Claim 10, 
characterized in that the medium stores a transmission data processing program including data 
transmitting means of outputting the transmission data and the control information of the 
communication link thereby transmitting to the client machine. 

Claim 12: The computer-readable recording medium according to Claim 10, 
characterized in that the medium stores a transmission data processing program including data 
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compressing means for the serialized transmission data, and decompressing means for the 
transmission data compressed by the compressing means. 

Claim 13: The computer-readable recording medium according to Claim 10, 
characterized in that the medium stores one or greater number of data compressing means, and 
data analyzing means of determining application or non-application of a compressing means 
selected from the above compressing means depending on data characteristic of the transmission 
data. 

Claim 14: The computer-readable recording medium according to Claim 10, 
characterized in that the medium stores a transmission data processing program including: 

retrieval command data generating means of generating serializing the retrieval command 
transmitted from the client machine thereby generating a retrieval command data; and 

retrieval command regenerating means of converting the retrieval command data into a 
retrieval command for execution of the database retrieval. 

Claim 15: A data transmission apparatus comprising a database-side micro server 
connected with a database server incorporating a database therein and a client-side micro server 
connected with a client machine, for exchange of data as in a table format, between the database 
server and the client machine via a network and the micro servers, wherein 

database-side micro server includes: 
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a computing device, a storing device, and a data input-output device capable of inputting 
and outputting data to and from the database server and the network; a retrieval command 
generating program of converting a retrieval command data inputted from the client-side micro 
server into a retrieval command for execution of the database retrieval; 

a data table generating program of generating a retrieval data table obtained by the 
database retrieval, in the storing device; 

a data attribute table generating program of generating a data attribute table containing 
description of data attribute of the retrieval data table, in the storing device; 

a transmission data generating program of serializing all items in the retrieval data table 
and data attribute table into a single string without adding additional information between the 
items, thereby generating a transmission data; 

a control information adding program of adding control information corresponding to the 
transmission data, to a head of the transmission data; 

a data exchange program of exchanging data with the database server; and 

a data transmission-reception program for information exchange with the client-side 
micro server via the network; whereas 

the client-side micro server includes: 

a computing device, a storing device, and a data input-output device capable of inputting 
and outputting data to and from the database server and the network; 

a retrieval serializing the command data generating retrieval command data program 
given by the client machine into the retrieval command data; 
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a data table regenerating program of regenerating, in the storing device, the retrieval data 
table and the data attribute table from the transmission data and the control information received 
from the server-side micro server; and 

a retrieved data reading program of reading the retrieved data from the regenerated 
retrieval data table and the data attribute table. 

Claim 16: The data transmission apparatus according to claim 15, wherein the 
database-side micro server and the client-side micro server includes a data 
compression-decompression program including a data compressing program and a 
decompressing program for the data compressed by the compressing program. 

Claim 17; The data transmission apparatus according to claim 16, wherein the data 
compression-decompression program includes 

one or greater number of data compressing programs, and 

data analyzing means of determining application or non-application of a compressing 
program selected from the above compressing programs depending on data characteristic of the 
transmission data. 
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EVIDENCE APPENDIX 

No evidence under 37 C.F.R. § 41.37(c)(l)(ix) is submitted. 



RELATED PROCEEDING APPENDIX 

No decisions under 37 C.F.R. § 41.37(c)(l)(x) are rendered. 
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